The present invention relates to a processing method for an operating system (hereinafter abbreviated as OS) in a multi-processing system.
The multi-processing system is one of the systems for improving the performance and reliability of a single processor system. Various types of such systems have thus far been proposed. Great advances in recent semiconductor technology has provided cheap and high performance LSI processors, resulting in easier hardware design of the multi-processor system.
It is said that a multi-processor system with a combination of n processors can not produce an up-grade of the performance by n-times that of the single processor. In this regard, for example, the combination of three processors provides a performance improvement of approximately 2.1 times at most over the single processor system. The major causes for hindrance of the performance improvement are, for example, conflicts in access to the main storage used in common among the processors, the conflict control associated with common use of the resource, and an increase of the overhead arising from the communication among the processors. A more important cause is that, although the number of execution steps of the OS is larger than that of the execution steps of the user program in a real time system, the OS is sequentially processed by a single processor.
For example, in a single processor, when the execution of a user's program A terminates, the program A issues a request for exit processing, and the OS is processed in response to the request. Then, the OS performs exit processing to check for each resource as to whether there is present or not the shared resource under reserve as a result of execution of the user's program by the processor, as shown in FIG. 1. If a certain shared resource is under reservation, the OS liberates the resource 1 from its reservation (steps A1, B1, C1), while at the same time it liberates other user's programs which are posted for reservation of resource 2 at the steps (A2, B2, C2). Finally, the OS performs the exit processing for the user's program A (step .circle.d ). The checks in these steps A1, B1, and C1 must be performed for all the idle or accessible resources. Further, although the processing steps A2, B2 and C2 following the checks are not dependent on the result of the checks, these checks and the succeeding processings are sequentially performed for the different resources. Further, a conflict control must be effected for the processing of the post for reservation of resource 1 (steps A2, B2, B2). For that reason, the exit processing by the OS consumes time.
When an input/output request to an input/output unit is issued from the user's program A being executed, the execution of the user's program A is interrupted, as shown in FIG. 2 and the OS is executed. The OS checks the reservation status of the I/O unit (step E1) and, if the I/O unit is idle or usable, it reserves the I/O unit (step E2) and arranges the control information for the I/O unit to activate the I/O unit (step .circle.e2 ). Then, the OS keeps the user's program out of its execution until the transfer of the I/O data is terminated (step .circle.e3 ). In this way, the input/output request is processed. Then, the OS finds a user's program of which the execution is requested (step .circle.f ), and then starts the execution of the user's program B. When the I/O data transfer requested by the user's program A terminates during the course of executing the user's program B, an I/O transfer termination interrupt interrupts the execution of the user's program B, and the OS operates for processing the interrupt. Then, the OS liberates the reservation of the I/O unit (step .circle.g ). and selectively activates an executable user's program (step .circle.f ), and starts again executing the user's program. As described above, the user's program B is interrupted in its execution and postponed in the termination of its execution by processing the termination interrupt of the I/O transfer against the user's program A which is not related to the program B in its own program execution. This problem arises from the fact that when an OS processing request is issued from a certain processor, the processing is executed by only that processor.